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D atabase applications commonly requi re unique se¬ 
quential keys for inserting new records into tables. 
For example, a call tracking system may allocate a 
case number or a billing system may allocate a customer 
id. In some applications, the sequential key may be the 
preferred method of retrieval (as in locating cases in a call 
tracking system). 

We present several client strategies for key allocation. 
One size does not fit all. System administrative policy, 
application features, and overall performance expecta¬ 
tions must be considered carefully in selecting an algo¬ 
rithm for generating sequential keys. Accordingly, we 
exami ne the fol lowi ng factors: 

1. Direct access versus stored procedure access 

2. Single versus multiple key allocation 

3. Error handling 

4. Explicit locking versus browse mode concurrency man¬ 
agement strategies 

The code samples discussed use VisualWorks 2.0 Small- 
talkfrom ParcPIace Systems and Sybase System lOfrom 
Sybase. The client/server dialog is implemented using 
the basic mechanisms of the VisualWorks 2.0 Database 
Connect driver for Sybase. 

DIRECT VERSUS STORED PROCEDURE ACCESS 

By direct access we mean the application issues SQL to 
generate the next key. Inthiscase, the application must be 
intimately knowledgeable of various schema manage¬ 
ment issues: Are the next key seed values all contained in 
the same tablewithin different records, or does each data 
table have a corresponding key table? Also, how does the 
client arbitrate multi-application access of the key table? 
Should the table be locked during sequential key alloca¬ 
tion or should the application select for browse? 

Sequential key allocation isagood candidateforstored 
procedure implementation. The function is simple, high¬ 
ly dependent on the schema, and a focal point of client 
activity. Should one application implement key allocation 
improperly, it could wreak havoc on the database. 

SINGLE VERSUS MULTIPLE KEY ALLOCATION 

Conceptually .single key allocation isthesimplest strategy. 
Each time a client requests a new key, it receives the next 


ordinal number. This ensures that selects ordered on the 
key parallel selects ordered on the insertion timestamp 
for each record. This may or may not be an application 
requirement, and assumes the key is allocated only after 
the record has been validated. If the client should aban¬ 
don the insertion and terminate, the key would be lost. 
Conversely, this strategy may be affected by when it is 
necessary in the end-user dialog to make the key avail¬ 
able. If the user must know the key prior to server-based 
validation, it is not possibleto guarantee that the key will 
parallel the insertion timestamp. 

There are many performance factors affecti ng key allo¬ 
cation implementation. Requesting keys is relatively 
expensive because the client must communicate with the 
server over the network. Also, because hundreds of clients 
may compete for the next key, there is a potential system 
bottleneck. Asolution isto have the server providea range 
of keys each time the client makes a request. How many 
keys is enough?The answer depends on the application. 
In fact, objects managed by an application most likely 
require different ranges. For example, in a call tracking 
system,case numbers may be required to be sequential in 
time, whereas new customer numbers may have no such 
requirement. Models should provide single and multiple 
key allocation strategies. We now examine three imple¬ 
mentations of key allocation. 

SIMPLE UPDATE AND SELECT KEY ALLOCATION 

I n this fi rst example, the database contai ns a table named 
KEYS. There is a record in KEYS for each data table requir¬ 
ing a sequential key. The method is called with the table 
name as its parameter and returns an integer value. 

nextKeyFor: aTableName 

I ans l 

self session 

begin; 

prepare: 'UPDATE KEYS SET serial = serial +1', 

' WHERE tableName ='", aTableName,'"'; 

execute; 

prepare: 'SELECT serial FROM KEYS where 
tableName ='", aTableName,"''; 

execute. 
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ans : = self session answer atEnd; next, 
self session commit. 

"'ans first first. 

The method works because the fi rst statement i nvokes a 
transaction that must place a write lock on the KEYS table. 
This first statement updates the serial value of the record 
whose tableName value contains the string aTableName. The 
next statement selects the seri al val ue and retu rns the i nte- 
ger to thecal ler.Thecommit releases any locks; other clients 
may proceed to complete the same dialog with the server. 

This code makes several assumptions. First, it does not 
explicitly check for any rollback condition. It may be that 
the client does not have rights to update the KEYS table. 
This method should encapsulate the execute statement 
with a handler that enforces a rollback on such condi¬ 
tions. The following code creates an example signal han¬ 
dler. In production code you will want to preallocate the 
signal handler. 

nextKeyFor: aTableName 
| ans noUpdateSignal| 

nollpdateSignal : = Signal new notifierString: 

'Unable to get the next key from ', 
aTableName. 

noUpdateSignal 

handle: 

[:ex | 

self adminConnection rollback. 

Dialog warn: ex errorstring, ex return] 
do: 

[self session 

begin; 

prepare: 'UPDATE KEYS SET serial = serial + 1', 

' WHERE tableName ="', aTableName,"''; 

execute; 

prepare: 'SELECT serial FROM KEYS where 
tableName ='", aTableName,"''; 

execute. 

ans : = self session answer atEnd; next. 

self session commit], 

"'ans first first. 

Second, there may be no record in the KEYS table contain¬ 
ing aTableName as the value of its tableName column. 
(Perhaps some coding error misspelled the table name 
string.) In this case, the code would execute without error 
but always return the most recent key in use. The end 
result would be an insertion error if there were a unique 
index on the key column of the data table for which the 
key is intended. This condition can be detected bycheck- 
ingtherowcount attribute for the session after each state¬ 
ment gets executed. It should be 1 i n each case. 

The final assumption is that the key must be pre¬ 
incremented. This is the type of schema assumption that 
is often documented too casually, causing problems 
down the road. If this method services all applications 
accessing the database, then this assumption is probably 
adequately handled; however, this is very unlikely. The 


more likely case isthat the table will be accessed by het¬ 
erogeneous clients: 4GLs, Smalltalks, C, C++, etc. This 
preincrement policy makes this function a good candi¬ 
date for stored procedure encapsulation rather than 
d i rect i mp I ementati o n. 

STORED PROCEDURE KEY ALLOCATION 

The next example suggests how the nextKey method may 
contract with a stored procedure called nextKey. 

nextKeyFor: aTableName 
'TiseSto red Procedures 
ifTrue: 

[self session 

prepare: 'nextKey ', aTableName,',', 
aNumber asString; 

execute. 

(self session answer atEnd; next) first first] 
ifFalse: 

[self embbededSQLNextKeyFor: aTableName]. 

I n this example, the database framework has some control 
over whether it uses stored procedures. If so, thefi rst clause 
gets executed, otherwise execution gets redirected to 
another method (a new name for the previous example). 

CONCURRENCY ISSUES 

One of the vital issues we’ve avoided so far is that of con¬ 
currency control. Two separate clients cannot execute the 
preceding examples at the same time. The two options 
are locking anti browsemode. Executing locks in thistype 
of method is a pessimistic form of concurrency control. 
It requires signal handlers to detect the lock condition 
and possibly repeat attempts until the competing client 
clears the lock. 

In our remaining example, we prefer an optimistic 
concurrency control strategy using what is known as 
browse mode. In browse mode, the client issues no lock 
requests. Instead, the row contains a column of type time- 
stamp. The database service updates the timestamp value 
each ti me it performs a select agai nst the row. I n request- 
ing the serial value, the client also requests the timestamp 
value. It then uses the timestamp value as a where clause 
restriction when updating the row to the incremented ser¬ 
ial value. Only the client with the most recent timestamp 
succeeds in updating the serial value. This success indi¬ 
cates to the method that it may return a valid key to its 
caller. All other clients executing the same method exe¬ 
cute their signal handler and make another attempt at 
fetching a new key. 

Browse mode requires that the select statement end 
with the words "FOR BROWSE." The target table must 
have a unique index and, as noted, a timestamp column. 

MULTIPLE KEY ALLOCATION IN BROWSE MODE 

Our final example demonstrates a rich set of services. The 
method returns a collection of one or more sequential 
integer keys for the table aTableName, enabling the client 
to (possibly) cache multiple key values. We also use 
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browse mode to implement an optimistic concurrency 
management strategy. 

The method iscomposed in four sections. The first sec¬ 
tion sets up the method by assigning a "1" to the attempts 
counter, allocating a stream to compose queries, and cre¬ 
ating a signal instance to manage any exception condi¬ 
tions. The second section defines the exception handling 
clause. When an exception occurs, the connection must 
rollback the transaction and increment the attempts 
counter. If more than 10 attempts occur, notify the user 
with a dialogue box and error out. Otherwise, just try 
again. The third section composes and executes two SQL 
statements. The first statement retrieves the key and time- 
stamp values; the second statement attempts to update the 
key value. This section checks the session rowcount value to 
verify that the update occurred. This value should be 1. 
The fourth and final section creates an ordered collection 
and assigns to it a sequence of anl nteger integers, begin¬ 
ning with the fi rst avai I abl e key val ue 

nextKeyFor: aTableName incrementBy: anl nteger 
| currentData timestamp nollpdateSignal attempts oc 
aStream | 
attempts : = 1. 

aStream : = (String new: 75) writeStream. 
nollpdateSignal : = Signal new notifierString: 

'Unable to get the next key from ', 
aTableName. 

noUpdateSignal 

handle: 

[:ex | 

self adminConnection rollback, 
attempts : = attempts +1. 
attempts > 10 ifTrue: [Dialog warn: ex 

errorstring, ex return], 

ex restart] 
do: 

[self adminConnection begin, 
self adminSession 
prepare: 

'select key, timestamp from ', 
aTableName ,' FOR BROWSE'; 
execute. 

currentData := self adminSession answer atEnd; 
next. 

timestamp : = currentData last. 
aStream 

nextPutAII: 'update'; 
nextPutAII: aTableName; 
nextPutAII: 'set key =Key+'; 
print: anl nteger; 

nextPutAII:' where timestamp ='; 
sqIPrint: timestamp, 
self adminSession 

prepare: aStream contents; 

execute. 

answer. 

self adminSession rowCount < 1 ifTrue: 


[noUpdateSignal raise], 
self adminConnection commit], 
oc : = OrderedCollection new: anl nteger. 
lastUsedld +1 to: lastUsedld + anl nteger do: [:i | oc 
add: i], 

"oc. 

Each of these examples is acceptable depending on as- 
sumptionsthat must be supported by the client. This last 
example, however, illustrates several important op¬ 
timizations. First, the algorithm for fetching the next key 
and updating its row on the server i sen apsu I ated byasig- 
nal handler. Second, the method checks the session row- 
count valueto ensu re theupdate actually occurred. If itdid 
not, the signal israised and the operation attempted upto 
10 times. Third, the SQL is constructed using a write 
stream; a faster strategy than successive string concatena¬ 
tion with commas. 

Despite the optimizations, the code is written for clarity 
over performance. A production version would create the 
signal at initialization time and keep it in a class-side dic¬ 
tionary. It doesn’t makesenseto create a new signal during 
each request for a new key. Also, it is important to allocate 
a string for the write stream that is very nearly the size of 
the largest SQL statement. Performance profiling demon¬ 
strates that writestream creation time isdominated by the 
size of the string allocated for the stream. Don't allocate a 
500- byte stri ng and thi nk the stream operations are savi ng 
you any ti me over stri ng operations with the comma oper¬ 
ator. The best solution is to create the string only once, cre¬ 
ating the write stream on that same string over and over 
with each call to the method. Finally, the ordered collec¬ 
tions provide convenient collection services. However, they 
are considerably slower than arrays The final section 
should probably be implemented with an array. 

It is not immediately obvious, but this strategy also al¬ 
locates a separate connection/session for servicing next 
key requests. It may be that this method executes in the 
context of saving many objects to the database bounded 
by a single begin/ commit pair. As each object gets saved, it 
must request the next available key, which (as illustrated) 
requires its own transaction control. This alternate ad¬ 
ministrative connection executes key retrievals within a 
separate transaction. (It is customary for browse mode 
strategies to employ two connections.) 

CACHING KEYS 

The remaining code illustrates how a client may cache 
multiple (sequential) keys. Thisstrategy is appropriate in 
many cases; it can greatly reduce the number of database 
requests, thus enhancing overall client performance and 
reducing network traffic. Without such a strategy, each 
insert operation generates two database transactions, first 
to fetch a key and second to perform the insert. 

nextKey 
I key] 

(keyCache isNil or: 

[keyCache i sEmpty]) continued on page 32 
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G ETTIN G REAL continued from page 19 

name first clusterl nBucket: empCIuster. 
name middle clusterl nBucket: empCIuster. 
name last clusterl nBucket: empCIuster. 

" cluster the address and its components" 
address :=anEmp address, 
address clusterl nBucket: addressCluster. 
address street clusterl nBucket: addressCluster. 
address city clusterl nBucket: addressCluster. 
address state clusterl nBucket: addressCluster. 
address zip clusterl nBucket: addressCluster. ]. 

Thiscolumn has described how to determine if clustering 
objects might help application performance and how to 
cluster objects using ClusterBuckets. My next column will 
discuss how to measure overall system performance and 
steps for tuning multi-user Smalltalk for higher transac¬ 
tion throughput. K 


THE BEST OF COMP.LANG.SMALLTALK 

continued from page23 

•Avoid commitment—This is another way of 
expressi ng the princi pie of postponi ng decisions but 
one that might strikeachord with younger or 
unmarried programmers. 

• It’s not a good example if it doesn’t work—This one 
comes from David Buck (dbuck@magmacom.com), 
who’s fed up with looking at example and test 
methods that haven’t been properly maintained as the 
codeevolved. I can'tthinkof a wayto applythisto life 
but it's good advice anyway. 

• Steal everything you can from your parents—A 
princi pie for those tryi ng to make effective use of 
inheritance or movi ng i nto their fi rst apartment. 

• Cover your a**—Like in a bureaucracy, the most 

i mportant thi ng i s to make su re that it i sn't your fault. 
M ake sure your code won’t have a problem even if 
thi ngs are goi ng very wrong elsewhere. SI 


SEQUENTIAL KEY ALLOCATION 

continued from page26 

ifTrue: [ keyCache : = self nextKeys: self 
keyCacheSize ]. 

key : = keyCache first. 
keyCache removeFirst. 

"key. 

If you choose to make the array optimization in the 
nextKeys: method, this method must be changed to insert 
nil values into the array as each key gets returned rather 
than using the removeFirst selector, ffl 

Dayle Woolston and Chris Kesler have been working with 
Smalltalk for 4 years building client/server database applications. 
They can be reached at dayle_woolston@novell.com and 
chris_kesler@novell.com. 
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